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Abstract 

This paper lists some new directions for research related to 
the Algebra of Communicating Processes (ACP). Most of 
these directions have been inspired by work on Subscript, 
an ACP based extension to the programming language Scala. 
Subscript applies several new ideas that build on ACP, but 
currently these lack formal treatment. 

Some of these new ideas are rather fundamental. E.g. it 
appears that the theory of ACP may well apply to structures 
of any kind of items, rather than to just processes. 

The aim of this list is to raise awareness of the research 
community about these new ideas; this could help both the 
research area and the programming language Subscript. 

Categories and Subject Descriptors D.3.2 [Programming 
Languages]: Dataflow languages 

General Terms Languages, Theory 

Keywords Algebra of Communicating Processes, ACP, 
data flow, concurrency, non-determinism 

1. Introduction 

The Algebra of Communicating Processes (ACP) is a con¬ 
currency theory that allows for concise specifications of 
event-driven and concurrent processes. It also helps formal 
reasoning about process behavior. ACP is good at describ¬ 
ing processes that communicate synchronously, and less at 
describing asynchronously communicating processes. 

The theory has been developed with mathematical rigor, 
mainly in the period 1982 to the end of the 20th century. 
In spite of its robustness ACP is not as much being used in 
the software engineering world as it could be. This is pitiful 
since both worlds could profit from exchanges of ideas. 

ACP is well applicable as a basis to extend existing program- 
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ming with nondeterministic expressiveness. We are develop¬ 
ing an ACP based extension to the programming language 
Scala by the name of SubScript[i] In a way Subscript walks 
ahead of ACP; it applies several ideas that would likely fit in 
ACP, but are not yet formalized. 

We think such formalizations are due for a formal specifi¬ 
cation of Subscript’s semantics. These could also bring new 
life into ACP research. 

The rest of this section introduces ACP and SubScripj^ In 
the next section we present the list of new directions. For 
each element we give an impression of the formal treatment 
that we foresee. 

1.1 ACP 

The Algebra of Communicating Processes a is an alge¬ 
braic approach to reasoning about concurrent systems. It is 
a member of the family of mathematical theories of concur¬ 
rency known as process algebras or process calculQ More 
so than the other seminal process calculi (CCS Ih) and CSP 
0), the development of ACP focused on the algebra of 
processes, and sought to create an abstract, generalized ax¬ 
iomatic system for processes. 

ACP uses instantaneous, atomic actions (a,b,c,...) as its main 
primitives. Two special primitives are the deadlock process 
6 and the empty process e. Expressions of primitives and 
operators represent processes. The main operators can be 
roughly categorized as providing a basic process algebra, 
concurrency, and communication: 

• Choice and sequencing - the most fundamental of alge¬ 
braic operators are the alternative operator (-f), which 
provides a choice between actions, and the sequencing 
operator (•), which specifies an ordering on actions. So, 
for example, the process (a-|-6) -c first chooses to perform 
either a or b, and then performs action c. How the choice 
between a and b is made does not matter and is left un¬ 
specified. Note that alternative composition is commuta¬ 
tive but sequential composition is not (because time flows 
forward). 

* Web site: www.subscript-lang.org 

^ These sections contain some text fragments literally copied or adapted 
from a paper presented at the Scala Workshop 2013 jS) about dataflow 
programming support in Subscript. 

^ This description of ACP has largely been taken from Wikipedia. 
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• Concurrency - to allow the description of concurrency, 
ACP provides the merge operator |j. This represents the 
parallel composition of two processes, the individual ac¬ 
tions of which are interleaved. As an example, the pro¬ 
cess (a • h) II (c • d) may perform the actions a, b, c, d in 
any of the sequences abed, acbd, aedb, cabd, cadb, edab. 

• Communication - pairs of atomic actions may be defined 
as communicating actions, implying they can not be per¬ 
formed on their own, but only together, when active in 
two parallel processes. This way, the two processes syn¬ 
chronize, and they may exchange data. 

ACP fundamentally adopts an axiomatic, algebraic ap¬ 
proach to the formal definition of its various operators. Using 
the alternative and sequential composition operators, ACP 
defines a basic process algebra which satisfies the following 
axioms: 


x + y 
{x + y) + z 

X + X 

(x + y)- z 
(x-y)- z 


y + x 

x+{y + z) 

X 

X ‘ z -\- y ‘ z 
x-{yz) 


The primitives 0 and 1, also known as 5 and e, behave 
much like the 0 and 1 that are usually neutral elements for 
addition and multiplication in algebra: 


0 -I- a: = x 

Q ■ X = 5 

1 • X = X 

a: • 1 = X 


There is no axiom for x ■ 0. 


X + 1 means: optionally x. This is illustrated by rewriting 
(a: -I- 1) • y using the given axioms: 

(x + l) -y = x-y+l-y 
= x-y + y 

The parallel merge operator || is defined in terms of the 
alternative and sequential composition operators. This defi¬ 
nition also requires two auxiliary operators: 

X II y = x^y + y^x + x\y 

• a:|[y - "left-merge": x starts with an action, and then the 
rest of X is done in parallel with y. 

• a:|y - "communication merge": x and y start with a com¬ 
munication (as a pair of atomic actions), and then the rest 
of X is done in parallel with the rest of y. 

The definitions of many new operators such as the left 
merge operator use a special property of closed process ex¬ 
pressions with • and -P: with the axioms as term rewrite rules 


from left to right (except for the commutativity axiom for 
-P), each such expression reduces into one of the following 
normal forms: (x + y), a- x,l, 0. E.g. the axioms for the left 
merge operator are: 

{x + y)^z = x^z + y^z 

a-xly = a - (x^y) 

l|[a; = 0 

0|[a: = 0 

Again these axioms may be applied as term rewrite rules so 
that each closed expression with the parallel merge operator 
II reduces to one of the four normal forms. This way it has 
been possible to extend ACP with many new operators that 
are defined precisely in terms of sequence and choice, e.g. 
interrupt and disrupt operators, process launching, and no¬ 
tions of time and priorities. 

Since its inception in 1982, ACP has successfully been ap¬ 
plied to the specification and verification of among others, 
communication protocols, traffic systems and manufactur¬ 
ing plants. 

In 1989, Henk Goeman unified Lambda Calculus with pro¬ 
cess expressions 0. Shortly thereafter, Robin Milner et al 
developed Pi-calculus ||71, which also combines the two the¬ 
ories. 

1.2 Subscript 

Subscript extends the Scala language with refinement con¬ 
structs that are called "scripts". Essentially these scripts are 
definitions of ACP-like processes. Eragments of Scala code 
that are enclosed in brace pairs serve as atomic actions. 
These fragments serve as operands in script expressions, to¬ 
gether with script calls, iterator operands and others. The 
symbol for normal parallel composition is &; in practice this 
is not as much used as "or-parallelism" denoted by | |. 
More on Subscript is explained using following examples 
are typical for Subscript; these apply most of the new ideas 
that this paper is about. 

1.3 Example: A GUI Application 

Suppose we need a simple program to look up items in a 
database, based on a search string. 



The user can enter a search string in the text field and then 
press the Go button. This will at first put a "SearchingE" 
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message in the text area at the lower part. Then the actual 
search will be performed at a database, which may take a 
few seconds (simulated by a call to Thread.sleep). Finally 
the results from the database are shown in the text area. 

In Subscript this could look lik^ 


iive 

= searchSequence ... 

searchSequence 

= searchCommand 


showSearchingText 


searchInDatabase 


showSearchResuits 

searchCommand = 

ciicked(searchButton) 


• The white space after searchSequence in the live 
script denotes sequential cormosition. Semicolons also 
mean sequential composition^ For new lines there are 
similar rules as in Scala, implying that these often denote 
sequential composition as wel|^ 

• The three dots in the live script (. . ., "etcetera") turn 
the main script into an "eternal" sequential loop of search 
sequences. 

• searchCommand represents the command that the user 
gives to make the search start. It comes down to clicking 
a button. 

• showSearchingText and showSearchResults 

are scripts that sets texts in the larger text area. 
searchInDatabase performs a search in the back¬ 
ground; meanwhile the GUI remains active. The exact 
dehnitions of these 3 scripts are beyond the scope of this 
paper. 

Scala has an "implicit conversion" mechanism, which can 
apply a method call to a value that appears in a program text, 
when such a method is in scope been marked as implicit. 
Subscript extends this mechanism by including script calls 
as well. So if the script clicked has been marked as 
implicit, its name may be left out, leaving: 

searchCommand = searchButton 


1.4 Extending the program 

Now we add some realistic requirements to the program. 

• The search action may also be triggered by the user 
pressing the Enter key in the search text field. 


^ The Subscript website shows versions of the same functionality in plain 
Java and Scala, that are much less concise and intuitive). 

^ These have a low operator priority. 

® In Subscript these new lines have an even lower operator priority. 


• The search action requires that the input text field is not 
empty; only then should the search button be enabled 

• The user should be able to cancel an ongoing search, by 
clicking a Cancel button, or pressing the Escape key. 

• The user can exit the application by clicking an Exit 
button, or by clicking in the close box at the window’s 
upper right corner. But exiting should first be confirmed 
in a dialog box. 



The 3 user commands will be: 


searchCommand = searchButton + Key.Enter 
cancelCommand = cancelButton + Key.Escape 
exitCommand = exitButton + windowClosing 


The first and second plus operators create exclusive choices 
between buttons and key codes. These operands are not 
processes, but data items for which implicit conversions 
to processes have been dehned (such as clicked and 
keyPressed). 

Script windowclosing acts on window closing events. 
Exiting is implemented using a process named exit that 
runs in or-parallel composition to the rest. The or-parallel 
operator is | |, it means that all operands happen; as soon as 
one finishes successfully then the other is terminated and the 
whole composition terminates successfully. In this case, the 
left hand operand is an eternal loop of search sequences; the 
right hand operand is a (probably) hnite loop. 

The exit process starts with the exit command being given; 
then a confirmation dialog is run; all to be repeated while the 
result of the conhrmation dialog is false. The result of the 
confirmation dialog is transferred using a dataflow operator 
to a while construct; this operator is a curly arrow that names 
and types the flowing data item. 

iive = searchSequence... || exit 

exit = exitCommand 

confirmExit ~~(b:Booiean)~~> whileflb) 


(! is the logical negation operator in Scala) 

Eor the search sequence we now add items at the start and 
the end. 
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searchGuard is an "active guard" containing a sequen¬ 
tial loop. It first checks whether the text field contains some 
text. If so, there is an "optional break", specified by the dot. 
This means that the sequence and thus also the guard may 
end successfully, so that searchConunandbecomes active. 
However maybe an event happens at the text field before the 
user issues this search command; then the check needs to be 
redone, etc (. . .). 

After searchCommand a new line follows; this separates 
the first line from the remaining five lines. Therefore the rest, 
including cancelSearch, can only become active after 
the searchCommand has happened. cancelSearch is 
preceded by a slash symbol, which stands for disruption: the 
left hand side happens, possibly disrupted when the right 
hand side starts happening. The parentheses group the items 
on the preceding lines, so that the whole becomes the left 
hand side of the slash operator. 

searchSequence = searchGuard searchCommand 
{ showSearchingText 
searchInDatabase 
showSearchResults 

) 

/ cancelSearch 

searchGuard = if (IsearchTF.text.isEmpty) . 

anyEvent(searchTF) 

cancelSearch = cancelCommand showCanceledText 


2. New Directions 

2.1 Algebra of Items 

In the previous example, buttons, key codes and event codes 
were added: 

searchCommand = searchButton + Key.Enter 
cancelCommand = cancelButton + Key.Escape 
exitCommand = exltButton + windowClosing 


Thanks to Scala’s implicit mechanism we can glue 
any kind of items together using the ACP operators. The re¬ 
sult is an algebra of general items rather than just of pro¬ 
cesses. 

A transformation may turn such an item specification to a 
process specification. In the above, the obvious transforma¬ 
tion are about receiving input. It is also possible to do the 
opposite: the specification may for instance instruct a test 
robot to generate button clicks etc. 

A particular application of such algebra’s of items is in lan¬ 
guage grammars: these are descriptions of certain text struc¬ 
tures, rather than processes that accept or produce such texts. 
The paper "Equivalence notions for concurrent systems and 


refinement of actions "M already covers some technical is¬ 
sues of such a generalization to an algebra of items. 

2.2 Generalized Communication 

The Algebra of Communicating Processes (ACP) 131 offers 
process communication through atomic actions that combine 
into other atomic actions. We may call this action-level com¬ 
munication. The binary action-level communication gener¬ 
alizes to synchronous communication with more than two 
parties. Namely, if a and b are such actions, and if a\b = d 
and also d\c = e, then obviously (a|&)|c = e. 

In practice though communication between processes may 
last longer than just a single atomic action. In general mul¬ 
tiple processes will share the execution of a sequence of 
actions, according to another process specificatior|^ Like in 
ACP with action-level communication, a generalization to 
more than 2 communicating parties was possible in that lan¬ 
guage. 

Now when communication of 2 or more parties is possible, 
why not say it is about 1 or more parties? The 1-party case 
then coincides with the notion of process refinement. 

In traditional programming languages refinements are known 
as functions, procedures and methods. For these there is al¬ 
ways 1 caller that calls a callee. In a process oriented lan¬ 
guage more than one caller may be required to call a callee, 
in a synchronous effort. For instance, a process describing a 
message transmission may have to be called by two parties: 
a sender and a receiver. 

Conceptually this generalization of normal refinements to 
synchronous communication with 1 or more parties is sim¬ 
ple and elegant. A formal treatment of this general com¬ 
munication seems to be well possible, though considerably 
more complicated than action-level communication. 

2.3 Combination with Lambda Calculus 

The presented exit script contains a dataflow arrow: 

exit = exitCommand 

confirmExit ~~(b:Boolean)~~> while! !b) 


The left-hand side of the arrow operator needs to pro¬ 
duce a boolean value for transmission to the right hand side. 
Technically this requires, among others, support for "anony¬ 
mous scripts" or, to use another phrase, "anonymous pro¬ 
cesses" or "process lambda’s". These are much compara¬ 
ble to "lambda’s" in functional programming languages, also 
known as anonymous functions. 

In the exit script the call to confirmExit is technically 
an anonymous script, and the same holds for while {! b). 
As stated in the section on ACP, both Milner and Goeman 
combined lambda calculus with process calculus. However, 
this was done for the process calculus CCS. The theoretic 


^ This has been implemented in a predecessor language of Subscript; for 
Subscript communication is still due at the time of writing. 
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treatment of a combination of lambda calculus with ACP is 
still lacking. 

2.4 Result values, exceptions and dataflow 

There is more to the previous dataflow example. In the 
subexpression 

confirmExit ~~ (b: Boolean)~~> while(!b) 


the left hand side, confirmExit, is to produce a 
boolean value for transport via the arrow to the right hand 
side. This requires a new notion: it should be possible to give 
a process may have a result value, which becomes available 
when the process has success. 

But such a process may also fail, e.g. when something goes 
wrong. In terms of modern programming languages that 
would coincide with an exception being thrown. Hence the 
result of a process may not only be the prospective yield, but 
also an exception. 

It is possible to specify how both the normal result value and 
the exception should flow. E.g., 

X ~~(b:Boolean)~~> y 
+~/~(e:Exception)—> z 


This means in Subscript: do script x; when this succeeds 
continue with y, handing it the yielded value. In case x ends 
in failure, probably an exception has resulted; then continue 
with z with the exception. 

Under the hood this uses a ternary construct 

do X then y else z 


A counterpart for this has not yet been specified for ACP; 
this does appear to be relatively straightforward. 

A formal treatment of result values for processes in ACP and 
their flows, will probably require much more effort. 

2.5 Iterations and their termination 

There are multiple forms of iterations for ACP processes. 
For a statically known "iterative sum" the symbol ^ is used 
with annotated limits, as in common mathematical texts. 
Likewise for iterative sequences there is J|, and occasion¬ 
ally for parallel iterations a large version of 11 exists. 

A more dynamic approach is the use of recursive specifica¬ 
tions, as in X = a - X + b, which denotes a sequence of zero 
or more a’s, terminated by a b. 

Lastly there are variations of the Kleene star in use, e.g. a*b, 
meaning the same as the foregoing recursive specification. 
Here the Kleene star is an operator, just like + and •. 

Subscript has recursion, but not the other two options. In¬ 
stead to support many kinds of iterations, there are various 
special operands, that may be used in conjunction with any 
operator such as -I-, ; and | |. Some of these operands have 
already been introduced in the examples: 


while marks a loop and a conditional mandatory break 

for much like while and like the Scala for- 
comprehension 

. . . marks a loop; no break point, at least not here 

. . marks a loop, and at the same time an optional 
break 

an optional break point 
break a mandatory break point 

These operands would need some formal treatment. Note 
that some are in fact easily defined in terms of others: 

• . . is a combination of . . . and . 

• while (b) is a combination of . . . and 
if ( !b) break. 

The meaning of the ellipsis operand (...) seems to be 
relatively easy to define. This is by defining a transformation 
of an expression with such an operand into an expression 
without such an operand. 

Consider for any operator, say * (which can actually be +, ; 
etc), a process xi * X 2 * * Xn- (Here these tiny dots stand 

for Xi terms). If any of these terms is the ellipsis operand, 
then 

• the entire expression should be replaced by the solution 
of the equation X = xi * X 2 * ■■■ * Xn * X 

• in this equation all occurrences of the ellipsis operand 
should be replaced by a either 0 or 1, whichever is the 
neutral operand for *. 

The treatment of break and . is harder. This is mainly 
due to the fact that these have informally been given mean¬ 
ings that depend on the governing operator. The differentia¬ 
tion appeared to be necessary to maximize applicability. 

2.6 Operator axioms style 

ACP axiomatizations of parallelism usually starts with an 
axiom applying two auxiliary operators: 

x\\y = x^y + y^x + x\y 

Here x^y means, informally speaking: the left hand side x 
should start with an atomic action; then the rest of x happens 
in parallel with the right hand side y. 

And x\y means: first x and y start to communicate by exe¬ 
cuting a shared atomic action; thereafter the a parallel com¬ 
position of the rest of x and y happens. 

A parallel composition may terminate successfully if both 
operands may terminate successfully. Therefore from the 
axiomatization the following should be deductible: 

111 1 = 1 

There is a problem here: should the 1 be produced in rules 
for the x|[y part or for the x\y part? Both do not seem to 
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fit; the former form is meant to express that one party starts 
with an atomic action; the latter is meant to express that both 
parties start by communicating with one another. 

This inconvenience is reflected in the treatment of the 1 in 
ACP publications: some let the 1 be produced in the x^y 
part, others apply the x\y part. 

A better approach may well be to introduce another auxiliary 
operator specifically meant to for producing I’s, as in 

x\\y = s(J\)y + x^y + y^x + x\y 

This way a minor change in the dehnition of x(]^y could 
yield a kind of or-parallelism: successful termination may 
occur when any of the two operands may succeed success¬ 
fully. 

Another fruitful change would be the introduction of an aux¬ 
iliary right-merge operator. 

x\\y = ^y + x^y + X^y + x\y 

This is really not needed for the parallel operator; but the 
right-merge operator is easily dehned in terms of the left- 
merge operator. 

xh = ylx 

The main use for this style with an extra auxiliary opera¬ 
tor is to enable a uniform approach for more operators, that 
may or may not be symmetric. In general defining axioms 
would start with something like 

X *y = xQ)y + x<r^ y + x ^y + x^H^y 

Here the asterisk is stands for any operator to be defined 
this way; the asterisk with arrows denote auxiliary versions 
for left-composition, right-composition and communication. 

2.7 And- and or-parallelism 

In Subscript programs the or-parallel operator | | occurs 
much more than the normal parallel operator &. The total 
family consists of 4 operators, two with and-like logic be¬ 
havior and two with or-like logic behavior: 

&, &&, I, I I 

The reason to have four parallel operators may come clear 
by an analogy with the same symbols for boolean expression 
operators, as used in programming languages C, C-H-, C#, 
Java and Scala: 

In those languages, the evaluation of boolean expressions 
x&y and x | y requires that both operands are evaluated. 

For the evaluation of boolean expressions x&&y and x | | y 
first the left hand side operand is evaluated; only if the result 
of that evaluation would not be decisive for the logic result, 
the right hand side is evaluated. So if for instance x evaluates 


to true in x & & y then y is evaluated, and that result sets the 
result of the whole. 

Likewise the process operators && and | | have disruptive 
capabilities: 

• I I terminates one operand as soon as the other hnishes 
successfully, and then the whole succeeds. 

• Likewise the and-parallel operator && terminates one 
operand as soon as the other terminates with failure. 

The axiomatic definition of these operators is helped by 
the style introduced in the previous subsection. The defi¬ 
nition with structural operational semantics (SOS) requires 
negative premises. It seems to be rather complicated to prove 
that the axiomatic and SOS definitions conform to one an¬ 
other. It is not yet clear whether current automatic proof sys¬ 
tems are capable to handle this. 

2.8 Interruption and disruption 

ACP literature dehnes "Mode transfer" operators to express 
disruption and interruption ID. Unfortunately these defi¬ 
nitions do not handle the cases that on operator equals 1. 
Worse, the provided dehnition for the interrupt operator can 
not be extended to handle the 10 

Namely, when 1 is added to the algebra, a • 1 = a. There¬ 
fore axioms LINTl and LINT2 in the paper by Baeten 
and Bergstra would imply 1 i—^ a = 1. However, from 
INTh-RINT: 1 I— a = something + a, which contradicts 
the previous equality. 

A related problem of the current ACP dehnition of interrup¬ 
tion is that it is optional, e.g, a i—^ h = a + h ■ a. This is not 
natural. If an interrupt is optional, why should after such an 
interrupt no other interrupts be allowed any more? Moreover 
there is no way of expressing that an interrupt is mandatory. 
Therefore Subscript will have a mandatory interrupt opera¬ 
tor. To make it optional, just add 1 to the right hand side: 

X %/ (y+1) 


But since it is natural to express that a process may be 
interrupted 0 or more times, sequentially. Subscript has also 
an operator for tha0 

X %/% y 


This "multi interruptions" operator also needs a formal 
dehnition. 

A particularity is that it does not have a neutral element. That 
is unfortunate, since various constructs in Subscript should 

* The underlying cause is that ACP researchers often studied minimal sys- 
terns that did not contain 1. This was because smaller systems may be stud¬ 
ied with more rigor. Also some ACP researchers had a low relatively ap¬ 
preciation for the 1, not realizing that it is able to express optionality in 
sequences, as shown in subsection 1.1. 

^ The notation may look strange; these operators belong to a family of "sus- 
pend&resume" operators; their symbols all start with %. The suspend/re¬ 
sume operators have not yet been implemented in Subscript. 
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behave more or less neutrally, in specific respects. For in¬ 
stance, an if-then construct that has no explicit else 
clause behaves as if it has an implicit else clause that behaves 
neutrally. Also the iteration operand . . . behaves neutrally, 
apart from the fact that it turns its governing operator into an 
iteration. 

Although no neutral element exists for % / %, it seems reason¬ 
ably safe to make constructs such as . . . behave as 0 when 
they are governed by the multi-interTuptions operator, apart 
from their specific aspects. 

2.9 Stream flow 

A special kind of dataflow may be defined for listening on 
a stream. Suppose s is a process that listens to a stream; 
every time a datum arrives from the stream an atomic action 
in t happens. Now at such occasions a script p should 
be executed on those data. This could be expressed as an 
iterating data flow operator; 

s ~~(d:Datuin)—» t 


The definition would require a "mandatory inten'uptions" 
operatoip^ 

X %/%/ y 


This performs x with the modification that each time that x 
succeeds y happens. When y succeeds then x may resume 
with its next action, etc; if there is no such action the entire 
process succeeds. 

A stream pipeline streams would be possible as in: 

s ~~ (d:Datum) ~~» t ~~ (d:Datum) ~~» u 


To make sense, the left hand side of the second arrow should 
not include s, since otherwise u would happen too many 
times. Therefore this flow operator should be right associa¬ 
tive. 

To merge to streams s and t with this flow operator would 
be like 


(s&t) —(d:Datum)—» u 


Splitting a stream would be like 

s ~~ (d:Datum) ~~» { t —(d:Datum)~~» u 
& V ~~ (d:Datum) ~~» w) 


’’’Like other suspend/resume operators this has not yet been implemented 
in Subscript. 

’' An earlier version of this paper stated a different meaning: "This performs 
X with the modification that each time after an atomic action in x happens, 
y happens". However, for the use in a dataflow operator, it is necessary that 
the left hand side produces a value that flows to the right; this only happens 
when the left hand side succeeds 


It seems that such stream features might both be relatively 
easy to add on ACP, after other forms of dataflow have been 
added; they may also lead to clear and appealing specifica¬ 
tions. 

2.10 Negation 

ACP may be viewed as an extension to Boolean Algebra. 
The values F (False) and T (True) would become 0 and 1 in 
ACP. The atomic actions are then a new class of basic ele¬ 
ment; they have a notion of time or at least sequence, and 
this breaks the commutativity of the multiplication. 
However, next to addition and multiplication. Boolean Al¬ 
gebra has also a negation operator. This suggests that ACP 
could also have such an operator. A simple definition would 
be that the negation of a process performs the actions of the 
process; only; 

when the original process may terminate successfully, the 
negation does not 

when the original process terminates without success, the 
negation terminates successfully. 

This is easily defined using the ternary do-then-else con¬ 
struct, that was touched upon in the Dataflow subsection: 

-X = do X then 0 else 1 


In a different definition be like the previous one, with the 
following extra rule: 

the negated process may terminate successfully whenever 
the original process negation cannot do so. 

Only rarely has such a construct been needed as a program¬ 
ming featur^^ 

2.11 Disambiguated choice 

Ambiguous choices are an issue in parsing texts according 
to given grammars. The following 3 grammars will lead to 
ambiguous choices: 

A B A C + A D 
(A B + 1) AD 
A B / A C 


Unambiguous versions would respectively look like: 

A (B A C + D) 

A (B A D + D) 

A (B + C + A C) 


Here the common summand A has been factored out. 
Such a transformation is most often possible, but some gram¬ 
mars look more natural with ambiguous choices. 

A first option to evade the ambiguous choice in Subscript 
would be to specify an or-parallel operator instead of the 
nondeterministic choice; | or | |. For instance, in 

These unary operators had been implemented in Subscript’s predecessor 
language, but not yet in Subscript itself. 
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3. Conclusion 


ABAC II AD 


the A could be programmed in such a way that multiple in¬ 
stances can succeed given the corresponding input. Next, 
when B would succeed, D should fail and vice versa. This 
way, either the ABAC part or the A D part would suc¬ 
ceed. The other or-parallel operator | could be used as well. 
But there is a third option. A disambiguating choice operator 
+ I could be defined so that the equivalence 

ABACI + IAD = A{BAC-I-D) 


would hold. 

An ACP paper by Baeten and Mauw presents an ap¬ 
proach for such an operator. It is defined using three aux¬ 
iliary operators. 

This approach seems unfit for implementation in Subscript; 
the main problem would be to determine when two atomic 
actions are essentially the same. A more natural way to spec¬ 
ify such relationships is using communicating scripts. In par¬ 
ticular, it will be possible in Subscript to define a script of 
which one or more instances may communicate with one an- 
otheiP^ 

script s,.. = scriptBody 


Now the disambiguating choice operator | + | is much 
like the exclusive-or operator -I-, the difference being that an 
atomic action in one operand need not exclude an atomic 
action in another operand, in case they communicate or have 
another kind of simultaneous occurrence. 

But this would not be all. There would also be a need for a 
disambiguating version of the sequence operator. Namely 

(A B l+l 1) AD 


would simply reduce to 

(A B -I- 1) AD 


We have presented a set of new ideas for ACP research. This 
list is not final; the work on Subscript will likely cause more 
such items to emerge. 

Adopting these ideas would make ACP wider applicable, 
while at the same time it would give a solid foundation for 
their counterparts in Subscript. 

ACP researchers who wish to coauthor publications in any 
of these directions are invited to contact the author. 
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We would need operators | ;, | | ;, | ; | that would give 
the following reductions: 
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A 
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1 1 

D) 

(A 

B 
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1) 1; 1 
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= A 

(B 

A 

D 

l + l 

D) 


Similarly a disambiguating version | / | of the disrupt oper¬ 
ator / would be needed. 

For each of these disambiguating operators, implementation 
and formal definition seem to be well feasible. 


Communication has not yet been implemented in Subscript. 
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